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Recursive  Data  Structures 


C.  A.  R.  Hoare 


Abstract .  The  power  and  convenience  of  a  programming  language  may¬ 
be  enhanced  for  certain  applications  by  permitting  data  structures  to 
be  defined  by  recursion.  This  paper  suggests  a  pleasing  notation  by 
which  such  structures  can  be  declared  and  processed;  it  gives  the 
axioms  which  specify  their  properties,  and  suggests  an  efficient 
implementation  method.  It  shows  how  a  recursive  data  structure  may  be 
used  to  represent  another  data  type,  for  example,  a  set.  It  then 
discusses  two  ways  in  which  significant  gains  in  efficiency  can  be  made 
by  selective  updating  of  structures,  and  gives  the  relevant  proof  rules 
and  hints  for  implementation.  It  is  shown  by  examples  that  a  certain 
range  of  applications  can  be  efficiently  programmed,  without  introducing 
the  low-level  concept  of  a  reference  into  a  high-xevel  programming 
language. 


The  work  on  this  paper  was  supported  in  part  by  National  Science 
Foundation  under  grant  number  GJ  36473X  and  ARPA  Research  Contract 
DAilC  13 -73 -C -0433. 
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1. 


Introduction 


In  a  language  such  as  ALGOL  68  [1]  or  PL/l  [2],  a  central  role  is 
played  by  the  concept  of  a  reference  or  POINTER.  In  ALGOL  68,  the 
reference  underlies  the  treatment  of  ordinary  variables,  result  parameters, 
data  structuring,  dynamic  storage  allocation,  indirect  addressing,  etc., 
and  in  PL/l  they  are  also  used  for  value  parameters,  and  even  for 
input/output.  However  there  are  many  reasons  to  believe  that  the 
introduction  of  references  into  a  high-level  language  is  a  seriously 
retrograde  step: 

(1)  It  reintroduces  the  same  unpleasant  confusion  between  addresses 
and  their  contents  which  afflicts  machine  code  programmers . 

(2)  In  ALGOL  68,  confusion  is  doubly  confounded  by  complex  coercion 
and  balancing  rules. 

(3)  In  Fl/l  the  explicit  allocation  and  deallocation  of  storage 
affords  unbounded  scope  for  complexity  and  error. 

(4)  The  variables  subject  to  change  by  a  program  statement  are  no 
longer  manifest  from  the  form  of  the  statement.  For  example,  if  x  and 
y  are  reference  variables 

x  :  =  y; 

obviously  changes  x  ,  but  a  statement  in  ALGOL  68  like 
x  :  =  y+l; 

may  change  a  ,  or  b  ,  or  any  other  variable  of  appropriate  type:  one 
variable  it  can't  possibly  change  is  x  '. 

(5)  16  is  possible  to  retain  a  reference  value  to  an  area  of  local 
workspace  which  has  been  deallocated.  In  PL/l  this  can  cause  disaster 
without  warning;  in  .ALGOL  68  certain  rather  complex  rules  ensure  that 
the  danger  can  sometimes  (but  not  always)  be  averted  by  a  compile-time 
check.  This  is  known  as  the  problem  of  the  "dangling  reference". 

(6)  In  distinction  from  values  of  all  normal  types  (integers,  reals, 
arrays,  strings,  files,...)  the  value  of  a  reference  can  never  be  input 

to  a  program,  nor  output  from  it  (except  possibly  in  a  total  post  mortem 
dump)  . 

(7)  The  use  of  references  reduces  the  efficiency  of  execution  on 
machines  with  instruction  lookahead,  data  prefetch,  pipelines,  slave 
stores  or  paging  systems,  counteracting  all  these  laudable  attempts  by 
hardware  to  make  a  machine  seem  faster  or  larger  than  it  really  is. 
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(b)  When  data  is  to  be  held  permanently  or  temporarily  on  backing 
store  (e.g.  files  on  tape  or  disk),  the  use  of  references  can  create 
insuperable  difficulties  to  implementor,  user,  or  both. 

(9)  Proof  methods  for  dealing  with  a  language  which  permits 
general  pointers  are  significantly  more  complicated,  whether  the  pointers 
are  used  or  not . 

There  appears  to  be  a  close  analogy  between  references  in  data  and 
jumps  in  a  program.  A  jump  is  a  very  powerful  murtipurpose  tool,  present 
in  the  object  code  produced  by  compilers  for  almost  every  machine.  But 
it  is  also  an  undisciplined  feature,  which  can  be  used  to  create  wide 
interfaces  between  parts  of  a  program  which  appear  to  be  disjoint.  That 
is  why  a  high  level  programing  language  like  ALGOL  60  has  introduced  a 
range  of  program  structures  such  as  compound  statements,  conditional 
statements,  while  statanents,  procedure  statements,  and  recursion  to 
replace  many  of  the  uses  of  the  machine  code  jump.  Indeed  perhaps  the 
only  remaining  purpose  of  the  jump  is  to  indicate  irreparable  breakdown 
in  the  structure  of  the  program.  Similarly,  if  references  have  any  role 
in  data  structuring  it  may  be  a  purely  destructive  one.  It  would  there¬ 
fore  seem  highly  desirable  to  attempt  to  classify  all  those  special 
purposes  to  which  references  may  be  put,  and  to  replace  them  in  a  high 
level  language  by  more  structured  principles  and  notations.  In  this 
task,  it  is  encouraging  that  ALGOL  60  [3]  has  already  isolated  two  such 
uses,  namely  the  procedure  parameter  and  the  variable  length  array,  and 
has  dealt  with  them  without  introducing  the  reference  concept.  Further¬ 
more  ALGOL  W  [It]  and  PASCAL  [5]  have  introduced  references  as  represen¬ 
tations  of  many-one  relationships  in  a  relational  ne swork,  and  have  done 
so  in  a  manner  which  mitigates  many  of  the  disadvantages  mentioned 
above  (as  compared  with  (say)  ALGOL  68  or  PL/l) . 

One  of  the  main  reasons  for  using  stored  machine  addresses  is  that 
the  amount  of  storage  that  will  be  required  by  an  item  of  data  is  not 
known  to  the  compiler.  In  this  paper  we  will  consider  a  class  of  data 
structures  for  which  the  amount  of  storage  required  can  actually  vary 
during  the  lifetime  of  the  data;  and  we  will  show  that  it  can  be 
satisfactorily  accommodated  in  a  high  level  language  using  solely  high 
level  problem-oriented  concepts,  and  without  the  introduction  of  refefenc 
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2. 


Concepts  and  Mot at ions 


The  method  of  specifying  the  set  of  values  of  a  data  space  by 
recursion  has  long  been  familiar  to  modern  logicians.  For  example,  the 
propositions  treated  in  conventional  propositional  calculus  may  be 
defined  by  the  following  four  rules: 

1.  All  proposition  letters  are  propositions. 

2.  If  p  is  a  proposition  then  so  is  — ,  p  . 

3.  If  p  and  q  are  propositions,  then  so  are 

(p  S.-  q)  and  (p  V  q) 

4.  All  propositions  can  be  obtained  from  proposition  letters  by 
a  finite  number  of  applications  of  the  above  rules. 

When  the  set  of  propositions  as  defined  above  is  treated  as  an  object 
of  mathematical  study,  it  is  known  as  a  "generalized  arithmetic";  and 
an  additional  axiom  is  postulated: 

5.  Two  propositions  are  equal  only  if  they  have  been  obtained 
by  the  same  rule  from  equal  components . 

Exactly  the  same  idea  is  familiar  to  programmers  in  the  use  of  the 
BNF  notation  for  the  definition  of  programming  language  grammars.  For 
example,  propositions  could  be  defined: 

(proposition)  ::=  (proposition  letter)| 

-1  (proposition)  | 

((proposition)  Sr  (proposition))! 
((proposition)  V  (proposition)) 

(proposition  letter)  ::=  (letter) 

Both  these  methods  of  defining  data  not  only  specify  the  abstract 
structure  of  the  data,  they  also  state  how  any  value  can  be  represented 
as  a  linear  stream  of  characters,  for  example: 

( P  &  (-  P  v  Q) )  • 

However,  we  wish  to  abstract  from  the  external  appearance  of  the 
data,  and  concentrate  on  its  structural  properties.  This  abstraction 
is  familiar  to  an  algebraist,  who  calls  the  resulting  data  space  a  word 
algebra  on  a  given  finite  set  of  generators .  A  generator  is  a  function 
which  maps  its  parameter(s)  onto  the  larger  structure  of  whi^h  they  are 
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immediate  components .  A  generator  with  no  parameters  is  known  as  a 
constant.  In  the  case  of  propositions,  four  generators  are  required: 

(1)  prop:  letter  -  proposition; 

which  converts  any  letter  into  a  proposition  letter  (logicians  often 
use  a  different  type  font  for  this) . 

(?.)  neg:  proposition  -  proposition; 
which  constructs  the  negation  of  its  argument. 

(i)  con.j,  disj:  proposition  x  proposition  -  proposition; 
which  takes  two  arguments  and  whose  result  is  their  conjunction  or 
dir  junction  respectively. 

In  symbolic  manipulation  programs,  it  is  common  to  deal  with 
variables,  parameters,  and  functions  whose  values  range  over  data 
spaces  such  as  logical  propositions.  In  a  language  like  PASCAL, 
which  permits  and  encourages  the  programmer  to  define  and  use  his  own 
data  types,  it  seems  reasonable  to  permit  him  to  use  recursive  definitions 
when  necessary.  A  possible  notation  for  such  a  type  definition  was 
suggested  by  Knuth  [6];  it  is  a  mixture  of  BNF  (the  j  symbol)  and  the 
PASCAL  definition  of  a  type  by  enumeration: 

type  proposition  =  (prop  (letter)  |  neg  (proposition)  | 

conj,  disj  (proposition,  proposition)); 

It  is  assumed  that  the  type  "letter"  has  been  predefined,  for  example  as 
a  subrange  of  characters 

type  letter  'A'  ..  'Z' 

The  effect  of  this  type  definition  is  threefold: 

(1)  it  introduces  the  name  of  the  type; 

)  it  introduces  the  names  of  its  generators; 

(j-)  it  gives  the  number  and  types  of  the  argument(s)  of  the 
generators  (if  any). 

Type  definitions  of  this  sort  we  re  suggested  by  McCarthy  in  [7  ]  • 

The  typ  is  intended  to  be  used  to  declare  variables,  parameters 
(and  functions)  ranging  over  the  type,  e.g.: 

PI, PS :  proposition ; 
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and  the  generators  can  be  used  to  define  values  of  the  type,  e.g.,  the 
|  sequence  of  instructions: 


PI 

=  prop 

('P'); 

P2 

=  neg 

(pi); 

P2 

=  disj 

(P2,  prop  ('0,')); 

P2 

=  conj 

(Pi,  re); 

would  leave  as  the  value  of  P2  a  proposition  which  would  normally  be 
written: 

I  (P  &  (— i  P  V  Q) ) 

In  most  languages  with  references,  the  use  of  recursive  type 
definitions  is  permitted  only  if  the  recursive  components  of  each 
structure  are  declared  as  references.  This  seems  to  be  a  rather  low 
level  machine  oriented  restriction;  after  all,  we  do  not  insist  that, 
recursive  calls  of  a  procedure  should  be  signalled  by  such  special 
notations.  It  is  true  that  a  recursive  data  structure  which  is  held  in 
a  conventionally  addressed  main  store  will  usually  be  represented  by 
references,  but  it  seems  a  good  idea  that  the  programmer  should  be 
encouraged  to  ignore  the  machine-oriented  details  of  the  representation 
(just  as  he  ignores  details  of  the  implementation  of  recursive  procedures), 
and  should  concentrate  on  the  more  pleasant  abstract  properties  of  the 
structure.  The  implementor  should  also  have  the  freedom  to  use  a 
different  representation,  for  example,  when  the  data  is  held  on  a  backing 
store.  Thus  the  programmer  may,  if  he  wishes,  imagine  a  machine  which 
allocates  a  fixed  amount  of  space  to  hold  the  current  value  of  a 
variable  of  recursive  typo;  and  if  it  is  called  upon  to  fit  in  a  larger 
value,  it  adopts  the  same  expedient  that  we  do  —  it  merely  writes 
smaller '. 

In  defining  operations  on  a  data  structure,  it  is  usually  necessary 
to  enquire  which  of  the  various  forms  the  structure  takes,  and  what  are 
its  components.  For  this,  I  suggest  an  elegant  notation  which  has  been 
implemented  by  Fred  McBride  in  his  pattern -matching  LISP  [8].  Consider 
for  example  a  function  intone ed  to  count  the  number  of  &s  contained  in 
*  a  proposition.  Like  many  functions  operating  on  recursively  defined 

data,  it  will  be  recursive: 
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(1) 

(2) 

(•) 

00 

(5) 

(6) 


function  andcount  (p:  proposition):  integer; 
andc ount  :  =  eases  p  oi_ 

(prop(c)  -  )| 
neg(q)  -  andcount(q) | 
conj(q,r)  -  andcount(q)  +  andcount (r)+l| 
disj(q,r)  -»  andcount(q)  +  andcount(r)) ; 


Line  (1)  declares  andcount  to  be  an  integer-valued  function  of  one 
proposition,  known  as  p  in  the  body  of  the  function. 

Line  (2)  states  that  the  result  of  andcount  is  assigned  by  computing 
the  following  expression.  This  is  a  "case  expression"  whose 
effect  will  depend  on  the  value  of  p  . 

Line  (;>)  states  that  if  the  value  of  p  is  a  proposition  letter  c  , 
the  result  is  zero. 

Line  (h)  states  that  if  the  value  of  p  is  a  negation,  let  q  be  the 
negated  proposition  and  the  result  is  found  by  computing  the 
andcount  of  q  . 

Line  (5)  states  that  if  the  value  of  p  is  a  conjunction,  let  q  and 
r  be  the  names  of  its  components,  and  the  result  is  one  more 
than  the  sum  of  the  ancounts  for  q  and  r  . 

Note  that  the  identifiers  c  ,  q  ,  r  are  like  formal  parameters:  they 
are  declared  by  appearing  in  the  parameter  list  to  the  It  ft  of  the 
arrow,  and  their  scope  is  confined  to  the  right  hand  side  of  the  arrow, 
only  as  tar  as  the  vertical  bar.  Their  types  are  determined  by  the 
types  given  in  the  declaration  of  the  corresponding  generator,  e.g., 
c  is  a  letter,  and  q  and  r  are  propositions.  We  shall  insist,  for 
the  time  being,  that  the  programmer  shall  not  make  assignments  to  these 
variables . 

The  language  feature  described  above  is  evidently  capable  of 
repressing  all  the  functional  aspects  of  LISP,  and  many  of  idle 
procedural  aspects  as  well.  For  example,  the  list  structure  of  LISP 
can  be  defined: 

type  list  =  (unit  (identifier)  j  cons  (list,  list)) 
where  th6  type  identifier  is  assumed  to  be  predefined.  The  function 
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cons  is  defined  as  part  of  this  declaration.  The  other  LISP  basic 
functions  can  be  programmed: 

function  car  (f:  list):  list; 

car  :=  cases  l  of  (atom  (id)  -  error | 

cons  (left,  right)  -  left); 
function  cdr  (i:  list):  list;  ...  similar  ... 
function  atom  (f:  list):  Boolean; 

atom  :=  cases  l  of  (unit  (any)  -*  true  I  cons  (x,y)  ->  false); 
function  equals  (el, £2):  Boolean; 
equals  :=  cases  il  of 

(unit  (idl)  -  cases  12  of  (unit  (id2)  ->  idl  =  id2j 

cons  (x,y)  -*  false) ) 

cons  (xl,yl)  -  cases  12  of  (unit  (id2)  -*  false  | 

cons  (x2,y2)  -* 

equals  (xl,yl)  &  equals  (x2,y2))) 

In  practice,  the  cases  notation  will  often  be  found  more  convenient,  clear, 
and  less  prone  to  error  than  the  functions  car  ,  cdr  ,  and  atom  .  For 
example,  the  familiar  append  function  may  be  written: 

function  append(fl,  £2:  list):  list; 
append  : =  cases  il  of 

(unit  (id)  -  if  id  =  NIL  then  12  else  error | 
cons  (first,  rest)  ^  cons  (first,  append  (rest,  i2))); 

Just  as  LISP  can  be  embedded  in  any  language  which  permits  recursive 
data  structures,  so  can  all  recursive  data  structures  be  represented  as 
LISP  lists,  and  processed  by  LISP  functions.  For  example 

con/j  ( '  P' ,  dis  j(neg( 1 P' ) ,  ’Q* ) ) 

can  be  represented  (in  S-expression  form): 

f'CONJ  'P  ( 'DISJ  ( ' NRG  »P)  ’Q)) 

An  andcount  function  for  propositions  represented  in  this  way  would  be: 
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andcount  :=  (atom(l)  -*0, 

car(f)  =  'NEG  -  andcount (cadr( l) ) , 

car(  l )  -  'CONJ  -  andcount (cadr(  l ) )  +  andcount (cacidr(  t) )  4  1, 
car(i)  =  'DISJ  -  andcount (cadr(  l ) )  +  andcount  (caddr(O) )  1 

Note  the  arrows  in  this  program  are  LISP  conditionals  .  This  example 
illustrates  some  of  the  advantages  of  the  type  declaration  for  recursive 
data  structures: 

(1)  The  check  against  the  error  of  applying  the  function  to  a  structure 
which  is  not  a  proposition  can  he  made  more  rigorous,  and  can  occur 
at  compile  time  rather  than  run  time. 

(2)  It  is  easier  to  check  that  all  cases  have  been  dealt  with. 

(3)  The  formal  parameters  seem  to  be  more  readable  and  perspicuous 
than  the  abbreviations  car  ,  cadr  ,  caddr  ,  etc. 

In  the  next  section  it  will  be  shown  how  a  compiler  can  sometimes 
take  advantage  of  the  extra  information  supplied  by  a  type  declaration 
to  secure  more  compact  representations  and  more  efficient  code  than  is 
usually  achieved  in  LISP. 

To  summarize  the  notational  conventions  introduced  in  this  section, 
here  are  the  syntax  specifications  of  recursive  type  declarations  and 
case  expressions: 

(type  declaration)  ::=  type  (type  identifier)  =  ((generator  list)) 
(generator  list)  ::=  (generator)  |  (generator) (or  symbol) (generator  list) 

(or  symbol)  ::=  |  (i-e.,  vertical  stroke) 

(generator)  ::=  (generator  identifier) | (generator  i  dent  if  ier)(  (type  list)) 
(type  list)  ::=  (type)  I  (type),  (type  list) 

(case  expression)  ::=  cases  (expression)  of  ((case  list)) 

(case  list)  ::=  (case  clause)  |  (case  clause)  (or  symbol)  (case  list) 

(case  clause)  ::=  (pattern)  -  (expression) 

(pattern)  ::=  (generator  identifier) (  (formal  parameter  list))| 

(generator  identifier) 

(formal  parameter  list)  ::=  (formal  parameter) | 

(formal  parameter),  (formal  parameter  list) 

(formal  parameter)  ::=  (identifier) 


3 •  Implementation 

The  normal  method  oi“  representing  a  recursive  data  structure  for 
processing  in  the  main  store  of  a  computer  is  as  a  tree  using  machine 
addresses  to  link  the  nodes,  and  a  small  integer,  called  a  tag,  in  each 
node  (or  with  the  address)  to  indicate  which  of  the  generators  was  used 
to  define  this  node.  Each  node,  contains  as  components  the  values  of 
the  arguments  of  the  generator,  which  may  be  themselves  addresses  of 
other  nodes,  or  many  be  just  simple  values. 

For  example,  in  the  case  of  a  proposition,  the  name  of  the  generator 
is  represented  by  an  integer  between  0  and  3  .  If  the  node  is  a 
proposition  letter  (tag  0),  this  will  be  followed  immediately  by  a 
representation  of  the  letter.  If  it  is  a  negation,  the  tag  1  is 
followed  by  the  address  of  the  negated  proposition.  In  the  remaining 
two  cases,  the  code  2  or  3  is  followed  by  a  pair  of  locations, 
pointing  to  the  components  of  the  conjunction  or  disjunction.  Thus  the 
value 

(P  &  (-.  P  V  Q.) ) 
would  be  represented  as: 


Of  course,  this  example  is  untypically  simple.  A  picture  of  a  more 
realistic  proposition  would  explain  why  the  programmer  may  prefer  not 
to  think  in  terms  of  references. 

On  many  machines  it  will  be  possible  to  pack  the  tag  in  with  one  of 
the  components  of  the  node,  or  pack  two  addresses  in  a  single  word, 
thereby  saving  a  word  of  storage  on  that  node.  It  can  be  seen  that  when 
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nodes  have  more  than  two  canponents  it  is  possible  to  use  less  space 
y  than  the  standard  LISP  representation  for  the  sane  information. 

The  call  of  a  'non-constant)  generator  involves  the  dynamic 
acquisition  of  a  **ew  words  of  c  ntiguous  main  storage,  and  planting 
in  them  the  values  of  its  simple  parameters,  and  the  addresses  of  its 
1  recursive  parameters.  The  value  returned  by  the  generator  is  the 

address  of  the  new  node.  There  is  no  need  to  make  a  fresh  copy  of  the 
recursive  components,  since  it  is  quite  permissible  for  two  separate 
variables  to  "share1'  the  same  canponents,  thus: 


PI: 


P2: 


P3: 


In  this  picture  PI  has  value  Q  &  (-1  P  V  Q.)  and  P2  and  P3  have  the 
same  value  P  &  (-,  P  v  Q)  .  However,  this  shared  use  of  storage  is 
entirely  Invisible  to  the  programmer,  who  has  no  means  of  finding  out 
whether  it  has  occurred  or  not.  This  is  because  the  prohibition  on  the 
selective  updating  of  components  of  a  structure  prevents  the  programmer 
from  changing  a  node  on  one  tree,  and  testing  to  see  whether  the  change 
has  affected  the  other.  The  same  restriction  also  prevents  the 
establishment  of  cyclic  structures,  like: 
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Such  a  structure  would  appear  to  have  the  "infinite"  value: 

(P  &  (P  *  (P  ft  •  •  •  V  Q))  V  Q)  , 

and  thic  would  fail  to  satisfy  the  axiom  of  finite  generation.  Thus  the 
prohibition  on  selective  updating  seems  to  be  a  vital  means  of  preserving 
the  integrity  of  recursive  data  structures,  as  well  as  permitting  a  more 
economic  "shared"  representations . 

The  tree  representation  using  addresses  is  not  the  only  possible 
representation  of  recursive  data  structures .  If  the  structure  is  to  be 
held  on  backing  store,  it  should  be  converted  to  a  linear  stream, 
replacing  every  address  by  the  stream  representing  the  tree  to  which  it 
points.  In  this  representation,  the  example  P  &  (->  P  V  Q)  would  appear: 


2 

0 

,  p. 

5 

1 

0 

•  p* 

0 

’  ’Q* 

This,  of  course,  will  require  copies  to  be  taken  of  all  shared  branches., 
thereby  usually  occupying  more  space;  but  in  general  the  elimination  of 
addresses  will  compensate  l'cr  this .  Of  course,  on  reinput  of  the 
structure,  it  would  be  advisable  to  reestablish  as  much  sharing  as 
possible;  before  acquiring  a  new  node  to  accommodate  given  values,  if  a  node 
already  containing  these  values  is  already  present  in  store,  it  should 
be  used  instead.  Indeed,  the  reuse  of  existing  storage  in  this  way  may 
be  adopted  as  general  policy,  which  can  be  effective  in  certain  kinds  of 
application  --  for  example,  it  makes  test  of  equality  very  cheap;  in  any 
case,  it  is  entirely  invisible  as  far  as  the  logic  of  the  program  is 
concerned.  In  a  conventional  non-associative  store  a  hashing  technique 

If 
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is  recommended  for  finding  a  n  xii  with  given  contents;  henee  in  LISP 
it  is  known  as  "the  hashing  cons"  [9  . 

If  sharing  is  used,  iu  is  no  Ion  er  possible  to  reclaim  all  the 
storage  alloeated  to  a  variable  on  exit  from  the  block  in  which  the 
variable  was  deelared,  since  its  components  may  also  be  eomponents 
of  the  value  of  some  variable  global  t  >  that  block.  In  order  to  reclaim 
storage  when  it  me  out  (and  it  soon  will)  it  is  necessary  to  use  a 
sean-mark  garbage  collector  invented  by  McCarthy  for  this  purpose  [10]. 

This  will  be  more  complicated  than  the  tandard  LISP  garbage  colleetor, 
sinee  it  will  have  to  deal  in  blocks  of  different  size,  and  it  will  have 
to  know  the  type  of  each  node  and  the  relative  position  of  each  address 
within  it.  In  many  application  ,  the  size  of  the  nodes  do  not  vary  too 
wildly;  so  the  problem  of  fragmentation  should  not  be  significant.  The 
eost  pei'  node  of  garbage  collection  should  be  no  greater  than  in  LISP, 
and  if  nodes  are  larger  than  two  words,  some  saving  in  time  may  be 
possible . 

The  case  expr  : sion  can  be  compiled  into  highly  efficient  code.  The 
value  being  considered  may  be  loaded  into  an  index  register.  The  tag  is 
then  used  to  do  an  indexed  jump  leading  to  the  portion  of  objeet  eode 
dealing  with  that  particular  ease.  There  is  no  need  to  eheek  the  range 
of  the  index;,  it  is  logically  impossible  for  it  to  be  wrong'.  If  there 
are  more  than  two  alternatives  this  eould  be  more  eompact  and  effieient 
than  a  sequence  of  tests  .  The  left  hand  side  of  the  arrow  generates  no 
eode  at  all.  In  eompiling  the  right  hand  side,  the  formal  parameters  of 
this  case  ean  be  accessed  by  means  of  a  single  reverse  indexed  instruction 
(Ross  [11])  requiring  a  single  store  aceess.  In  accessing  the  third  or 
subsequent  component  of  a  node  this  will  be  more  compact  and  effieient 
than  the  LISP  use  of  cadr  ,  eaddr  ,  etc. 

With  reasonable  cooperation  from  the  programmer,  this  implementation 
would  seem  to  offer  a  significant  improvement  on  the  effieieney  of 
eompiled  LISP,  perhaps  even  a  faetor  of  two  in  spaee  x  cost  for  suitable 
applications .  But  even  more  significant  may  be  the  fact  that  normal 
operations  on  numbers,  characters,  bits,  ete.,  ean  be  eainued  out  with 
direet  maehinc  code  instructions,  without  the  preliminary  run  time  type  eheek 
which  can  be  so  cumbersome  in  eompiled  implementations  of  LISP.  Thus  the 
overall  improvement  might  sometimes  approach  an  order  of  magnitude. 
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U .  Axioms 


The  axioms  for  a  recursive  data  type  are  losely  modelled  on  the 
corresponding  informal  definition  of  the  type  as  given  in  the 
beginning  of  Section  Note  that  the  fourth  axiom  is  expressed  quite 
informally  •  in  its  noimal  formalization  it  appears  as  a  principle  of 
"structural  induction".  Consider  any  predicate  p(q)  ,  which  we  wish  to 
prove  true  of  all  propositions  q  ,  i.e.,  we  wish  to  prove 

Yq :  proposition .  p(q) 

The  principle  of  structural  induction  states  that  this  can  he  established 
by  pr  tving  the  theorem  for  all  the  ways  in  which  a  proposition  q  can 
be  gem  rated;  and  furthermore  in  these  proofs  p  may  be  assumed  true  of 
all  propositional  components  of  q  .  This  may  be  expressed  in  the  proof 
rule : 

Vc :  letter.  p(prop(c) ) 

Vp:  proposition.  o(p)  =»  °(nog(p)) 

Vp,q:  proposition.  p(p)*«(q)  =»  p(con,j (p,q))  & p(disj (p,q)) 

Vq :  proposition.  p(q) 

The  first  three  lines  of  this  rule  are  the  antecedents,  and  the  last  line 
is  the  conclusion  of  the  deduction. 

The  fifth  axiom,  dealing  with  equality,  is  most  easily  formalized 
by  giving  axioms  defining  the  meaning  of  the  cases  expression, 
for  propositions  the  axiom  takes  the  form: 

5 •  eases  prop(d)  of  ( . . . jprop(c)  -  e| . . .)  =  e^ 

&  cases  neg(p)  of  ( . . . |neg(q)  -  e| . . . )  =  e^ 

&  cases  conj (p,q)  of  ( . . .  |conj(r,  s)  -  e|  . . .)  =  e^ 

&  cases  dis.j  (p,  q)  of  (  . . .  |disj(r,  s)  -e|...)  = 
where  e^  means  the  expression  formed  from  e  by  replacing  all  free 

y 

occurrences  of  the  variable  x  by  the  expression  y  (with  appropriate 
modifications  of  bound  variables  when  necessary) . 
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The  question  now  arises,  are  these  axioms  suffieiently  powerful  to 
prove  everything  we  need  to  know  about  recursive  data  structures?  Of 
course,  this  question  is  not  precise  enough  to  permit  a  definitive 
answer;  but  our  confidence  in  the  power  of  the  axioms  can  be  established 
by  showing  their  close  analog;/  with  the  Peano  axioms  for  natural  numbers, 
which  have  been  found  adequate  for  all  practical  purposes  of  arithmetic. 
For  they  too  can  be  defined  as  recursive  data  structures: 

type  M  -  (zero,  succ(NN)); 

and  the  cases  notation  permits  the  traditional  method  of  defining 
recursive  functions,  for  example: 

function  plus  (m,n:  Nil) :  NN; 

plus  :=  cases  n  of  (zero  *  m|succ(p)  -»  sue c( plus (m,p) ) ) ; 

The  axioms  for  natural  numbers  defined  as  a  recursive  data  structure 

are 

(1)  zero  is  an  NN 

(2)  if  n  is  an  NH  ,  so  is  succ(n) 

(3)  p(zero) 

¥n:  NN.p(n)  =»  p(succ(n)) 

Yn:  NW.  o(n) 

(it-)  cases  zero  of  (zero  -  e  J  succ(n)  -  f)  -  e 
Sc  cases  suce(m)  of  (zero  -  e  |  succ(n)  —  f)  = 

Axioms  (1)  and  (2)  are  the  same  as  Peano' s.  Axiom  (3)  is  the  principle 
of  mathematical  induction.  From  Axiom  (1)  we  can  readily  prove  the 
remaining  two  Peano  axioms : 

1.  succ(n)  /  zero 

Proof  by  contradiction:  assume  succ(n)  =  zero 

cases  succ(n)  of  (zero  ->  true  j  succ(n)  —  false) 

=  cases  zero  of  (zero  —  true  |  succ(n)  -*  false) 

false  =  true  by  axiom  it. 
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2.  succ(m)  =  succ(n)  =»  rn  n 
Proof:  assume  the  antecedent. 


-  zero  |  succ(m)  —  m) 

-  zero  |  succ(m)  -  m) 

n 

It  is  worthy  of  note  that  when  none  of  the  generators  have  parameters, 
the  recursive  data  structure  reduces  to  a  PASCAL  type  definition  by 
enumeration,  and  the  axioms  still  remain  valid.  For  example,  the  Boolean 
type  may  be  defined: 

type  Boolean  =  (true  |  false) ; 

# 

and  the  axioms  are: 

(1)  true  and  false  are  Booleans, 

(2)  P(true) 

P( false) 

Vb:  Boolean .  p(b) 

(})  cases  true  of  (tine  -  e  j  false  -  f)  e 

cases  false  of  (true  -  e  |  false  -  f)  =  f 

If  desired,  the  notation  "  if  B  then  e  else  f  "  may  be  regarded  as  an 
abbreviation  for  "  cases  B  of  (true  -  e  |  false  -  f)  ". 


hence  cases  succ(m)  of  (zero 
=  cases  succ(n)  of  (zero 


m  in 

m  =  in 
m  n 


l  .e . . 


m 


If 


Classes 


Many  interest  in  :  algebras  an  not  word  algebras  --  for  example, 
iini-1  -  set.  and  Unite  irappinf  s  ( sparse  arrays).  However,  they  can 
be  represented  as  sub s ot .  ol  si  word  algebra,  consisting  of  elements 
satisfying  some  additional  property  mown  as  an  invariant  for  that  type. 

A  type  which  is  a  subset  of  a  word  algebra  will  be  called  a  class.  In 
order  to  ensure  that  each  newly  generated  value  of  the  type  will  actually 
satisfy  the  invariant,  the  programmer  must  have  the  ability  to  specify 

(1)  The  initial  value  of  any  declared  variable  of  the  class. 

(°)  The  fu:  ction(s)  which  are  to  be  used  to  generate  all  other  values 
of  the  class. 


A  programming  language  should  ensure  that  the  actual  generators  for  the 
recursive  class  are  never  used  outside  the  bodies  of  the  function(s).  In 
this  way,  by  proving  that  there  functions  preserve  the  invariant  (whenever 
their  parameters  satisfy  it),  it  is  possible  to  guarantee  that  all  values 
evei  generated  will  be  within  the  desired  subset.  This  idea  was  expounded 
in  [12]. 


As  an  example,  consider  the  representation  of  a  set  of  integers.  For 
this  purpose  we  shall  use  a  sin  ,1c -chained  list  of  integers,  which 
possesses  the  additional  invariant  properly  of  being  sorted.  The 
operations  required  for  a  i  et  an  (say)  insertion  of  a  possibly  new’ 
clement,  deletion  oi  a  possibly  present  element,  and  a  test  of  membership 
of  a  possible  element .  A  suggested  form  for  the  class  declaration  may  be 


iy 


(1) 

(2) 


(3) 


class  intset  (empty  j  list (int set,  integer)) 

begin  function  insertion^ :  intset,  i:  “integer):  intset; 
insertion  :  cases  s  of 

(empty  —  list ( empty,  i) j 
list (rest, j)  -  if  i  =  j  then  s 

else  if  i  >  j  then  list( insertion(rest, i) ,  j) 
else  list(s,i)) ; 

function  deletions:  intset,  i:  integer):  intset; 
deletion  :=  cases  s  of 

(empty  —  empty | 

list ( rest, j)  -  if  i  =  j  then  rest 

else  if  i  >  j  then  list (deletion(rest, i) ,  j) 
else  s) ; 

function  has(s:  intset,  i:  integer):  intset; 
has  :=  cases  s  of 

(empty  -  false j 

list(rest,j)  -  if  i  =  j  then  true 

else  if  i  >  j  then  has(rest,i) 
else  false)  ; 

intset  :=  empty 
end  intset; 


Notes 

(1)  Introduces  the  class  name  intset  ,  and  declares  that  it  will  be  a 
subset  of  the  recursive  type  with  generators  empty  and  list.  The 
scope  of  these  generator  names  is  confined  to  this  class  declaration. 

(2)  The  body  of  the  class  declaration,  as  in  [12],  has  the  form  of  a 
block,  in  which  are  declared  those  procedures  and  functions  which  are 
to  be  used  by  the  programmer  on  values  of  the  class,  namely  the 
functions  insertion  and  deletion  and  has  . 

(3)  The  body  of  the  block  specifies  the  initial  value  of  all  declared 
variables  of  the  class.  The  name  of  the  class  itself  is  used  for 
this  purpose. 
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It  ia  the  intention  that:  a  class  can  be  used  in  the  same  way  as  a 
type,  for  example: 

declaration 

(including  initialization  to  empty) :  R,S:  intset; 

assignment:  R  :  insertion(S,37) 

S  :  =  R;  R  :=  deletion(R, 56) ; 

test:  if  has (R, 37)  then  ... 

As  suggested  in  [12],  the  criterion  of  correctness  of  a  class  ean 
be  expressed  in  terms  of  an  invar j ant  and  an  abstraction  function. 

The  abstraction  function  which  maps  each  list  onto  the  set  which  it 
represents  ean  be  defined  by  recursion 

t7(i:  intset)  =  cases  1  of 

(empty  -  null  seu| 
list(ll, i)  -  [i]  U£7(£l)); 

and  the  invariant  can  be  expressed 

sorted(£:  intset)  =  ^,  cases  l  of 

(empty  -  true| 

list(£l,i)  -  i  =  min(i7(l))). 

The  correctness  of  the  insertion  function  ean  now  be  formally 
expressed. 

sort ed( s)  [body  of  insertion]  sort ed( insertion)  &  #(  insertion)  =  [i]Ut7(s) 

Since  insertion  is  a  recursive  function,  the  proof  of  this  will  require 
assumption  of  the  correctness  of  the  recursive  call,  namely: 

"  insertion(rest,i)  ".  This  hypothesis  may  be  expressed: 

[sorted(rest)  =s]  sorted(insertion(rest,j.))  & 

&  tf( insert ion(rest,i))  =  [i]Uo7(rest)  ...hypothesis 

in  which  the  antecedent  is  true  for  all  intsets,  and  may  be  omitted. 

}  Using  the  rule  of  assignment,  and  distributing  function  application 

through  the  eases,  we  obtain  the  following  lemma: 


19 


sorted(s)  =»  cases  s  of 

(empty  -  sorted(  list  (empty,  i) )  list  (empty,  i) )  =  {i}  \\tf(  c)  (1) 

list(rest,j)  -  if  i  =  j  then  sort  eel  ( c)  &#(  s)  =  [i]U<7(s)  (2) 

else  if  i  > j  then  sorted(ld st(insertion(rect, i) , j) )  (3) 

4 #(  list ( insertion( rest, i) ,  j) )  =  {i}UC7(c)  (4) 

else  corted(list(s,i) )  (5) 

4  <7(list(s,i) )  ={i}Ue7(s)  (6) 

tlach  case  can  he  readily  proved  from  the  definition  of  (J  and  sorted  ; 
no  further  inductions  are  required. 


6.  Memo  Functions 


In  this  section,  we  shall  explore  a  particular  ca.se  of  selective 
updating  of  components  of  a  recursive  data  structure,  which  enables  the 
programmer  to  secure  the  advantages  of  the  memo  function  advocated  by  Michic  [13]. 
Consider  the  old  example  of  differentiation  of  symbolic  expressions. 

The  simplest  impl an en t at i on  is  to  define  expressions  as  a  type: 

type  expression  =  (constant (real)  |  variable( identifier) | 
minus (expression) | 

sum,  product,  quotient (expression,  expression)); 
and  define  the  derivative  as  follows: 

function  derivfe:  expression,  t:  identifier):  expression; 
deriv  :=  cases  c  of 

(const ant (any)  -  constant (0)  | 
variable(x)  -  if  x  =?  t  then  constant (1) 

else  constant (0) j 
minus(u)  -  minus (deriv(u)) | 
sum(u,v)  -  sum(deriv(u)  ,dcriv(v) )  j 

product (u, v)  -  sum( product (u, den iv(v) ) , product (v,deriv(u)) )  j 
quotient (x,y)  -* 

quotient  ( sum(  deriv(u) ,  product  (minus  ( e) ,  deriv(  v) ) ) ,  v) ) ; 

Using  these  declarations  we  may  write: 

position,  speed,  acceleration:  expression; 
position  quotient (const ant (3) ,variable( 't ')) ; 

speed  :-  dcriv(position, variable( * t * ) ) ; 
acceleration  :=  deriv( speed,  variable(  't ' ) ) 

But  this  implementation  can  invo3.vc  heavy  penalties  both  in  space 
and  time: 

(l)  A  large  amount  of  space  will  be  wasted  in  storing  expressions 
of  the  form 

e+0  ,  ex  1  ,  exO  ,  etc . 

This  may  be  mitigated  by  declaring  expressions  as  a  class,  in  which  the 
generation  of  such  redundant  expressions  is  inhibited,  by  the  use  of 
programmed  functions . 


I  -)  i  expression  :i  s.  to  he  u  j  iTcrentiated  repeatedly  with 
respect  to  the  Prune  variable,  much  t  ji;i<  and  apace  can  bo  spent  on 
re- evaluating  the  derivatives  of  the  subexpressions ;  this  lime  could  he 
saved  if  the  previously  computed  derivative  were  stored  as  a  third 
component  of  each  node  representing  a  sum,  a  product  or  a  quotient. 

The  value  oi  this  component  (known  as  a  memo  component)  starts  off  as 
unknown",  but  when  the  derivative  of  this  subexpression  is  computed, 
it  is  stored  here:  and  if  the  derivative  is  required  again,  the  stored 


value  is  used  instead  of  being  recomputed. 

For  the  sake  of  simplicity,  in  the  following  program  we  have 
assumed  that  all  derivatives  are  taken  with  respect  to  the  variable  't'; 
also,  the  functions  perform  only  the  most  trivial  of  simplifications. 


In  a  serious  symbolic  manipulation  program,  all  these  functions  would 
be  much  more  complicated. 


^_lass  expression  (variable( identifier) | constant (real)  |mi( expression) | 

su,pr,  qu( expression, expression,  (unkn own ,  known ( expr e s s ion ) ) ) ) 
begin  constant  aero  ^  constant(O),  one  =  eonstant(l) ; 
function  s\un  (left,  right :  expression):  expression; 

sum  if  left  =  aero  then  right  else  if  right  =  aero  then  left 

else  su (left, right, unknown) ; 
function  inmus(e:  expression):  expression; 

minus  :=  eases  e  of  (eonstant(x)  -  eonstant( -x) ] 

mi(f)  ->  f  |  else  mi(e)) ; 

function  product (left, right :  expression):  expression; 
product  :  if  left  =  aero  v  right  -  one  then  left 
else  if  right  =  aero  V  left  =  one  then  right 
else  pr (left, right, \mknown) ; 
function  quotient (left, right:  expression):  expression; 
quotient  :=  if  left  =  aero  v  right  =  one  then  left 


else  qu (left, right , un mown ) ; 


function  dbydt(e:  expression)  -  expression; 
cases  e  of 


(M 


(variable (id) 
constant (any) 
mi(u)  -  dbydt 
su(u,  v, deriv) 


pr(u,v, deriv) 


-  dbydt  :=  if  id  =  f t f  then  one  else  zero| 

-*  dbydt  :=  zeroj 

:=  minus  (  dbydt  (u) )  | 

-  cases  deriv  of 
(known(f)  -  f| 

unknown  -  [dbydt  :  =  sum  ( dbydt  ( u) ,  dbydt  ( v) )  ; 
deriv  :=  known ( dbydt )})  | 

-  cases  deriv  of 


(known(f)  -  f 


unknown  -  [dbydt  :=  sum  (product  (u,  dbydt  (v) ) , 

product  ( v,  dbydt  (u) ) ) ; 
deriv  :=  known (dbydt) }) | 
qu(u,  v, deriv)  -*  cases  deriv  of 
(known(f)  -  fj 

unknown  -  [dbydt  quotient  (sum  (dbydt  (u) , 

minus  (product  ( e,  dbydt  (v) ) ) ) ,  v) 
deriv  :  =  known  ( dbydt )  ] ) ) ; 


expression  :=  zero 
end  expression; 


Notes 

(1)  The  PASCAL  constant  declaration  can  here  be  used  to  save  space  and 
time  and  trouble. 

(2)  It  seems  a  convenience  to  write  else  to  stand  for  all  the  cases  not 
explicitly  mentioned. 

(3)  It  is  also  convenient  to  use  the  name  of  a  function  as  a  variable 
inside  its  body  (except,  of  course,  when  it  has  actual  parameters)  . 

(4)  {  }  are  used  for  begin  end. 

The  correctness  of  this  class  obviously  depends  on  the  preservation 
of  the  invariant  that  if  e  has  the  form  su  ,  pr  ,  or  qu  ,  then  its 
memo  component  either  contains  the  value  unknown  or  known(  dbydt ( e) )  ; 
or,  more  formally: 

Ve,u,  v,d:  expression,  e  =  su(u,  v, known (d) )  v  e  =  pr(u,  v, known (d) ) 

Ve  =  qu(u,  v, known (d) )  =>  a  :=  dbydt (e)) 
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Furthermore  the  abstraction  function  for  the  class  must  not  mention 
the  memo  component.  It  is  this  that  makes  the  existence  of  the  third 
component  logically  invisible  to  tin,  user  of  the  class,  although  one 
hopes  that  he  notices  the  gain  in  efficiency. 

It  is  noteworthy  that  the  use  of  selective  updating  immediately 
permits  establishment  of  cyclic  structures,  but  because  of  its  logical 
invisibility,  this  docs  not  seem  to  matter.  For  example,  after  a  series 
of  assignments  like  those  shown  on  page  21, 

position,  speed,  acceleration:  expression; 

position  quotient (constant (;>) , variable ( 't' )) ; 

speed  : -  dbydt (position)  ; 
acceleration  :=  dbydt ( speed) ; 


A  diagram  of  the  stored  structures  will  be: 


position: 


speed: 


acceleration: 
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The  use  of  mem.'  component!:  door  not  invalidate  the  sharing  of 
subtrees,  again  because  of  thf  invisibility  of  the  updating.  Indeed, 
its  main  benefits  are  directly  due  to  the  preservation  of  sharing,  and 
can  be  increased  by  increasing  the  amount  of  sharing.  If  the  memo  function 
method  is  widely  used,  it  becomes  very  attractive  to  choose  the  "hashing" 
technique  of  storage  allocation.  However,  in  the  use  of  this  technique, 
it  would  be  desirable  to  ignore  the  contents  of  the  memo  component,  so 
that  if  a  newly  generated  expression  was  identical  to  one  in  which  the 
memo  component  was  already  mown,  they  would  still  be  correctly  identified, 
and  the  derivative  of  the  newly  generated  expression  would  be  available 
"for  free".  For  this  reason,  it  would  seem  to  be  a  good  idea  for  a 
programming  language  to  insist  that  a  programmer  single  out  a  memo 
component  by  a  special  form  of  declaration,  say  by  prefixing  it  by  the 
word  memo  .  A  similar  method  has  been  used  successfully  in  some  large 
theorem  proving  systems  f  lb  ] . 

The  language  feature  defined  here  places  on  the  programmer  the 
responsibility  for  correct  maintenance  of  a  memo  component;  and  it  helps 
him  in  this  only  by  supplying  an  appropriate  proof  method.  This  has 
the  advantage  that  the  programmer  can  readily  control  the  nature  and 
amount  of  information  to  be  memorized.  For  example,  if  partial  derivatives 
are  required  with  respect  to  exactly  three  variables,  three  memo 
components  can  be  declared.  If  the  identity  of  the  controlled  variable 
is  not  known  in  advance,  it  can  also  be  stored  in  a  memo  component,  so 
that  repeated  differentiation  with  respect  to  the  same  variable  will 
always  be  efficient,  although  'when  a  different  variable  is  used,  the 
memory  is  overwritten.  Or  the  programmer  can  maintain  a  small  list  of 
such  variable/value  pairs,  choosing  to  "forget"  certain  of  them  when  the 
list  rets  too  long.  Finally,  h°  can  choose  which  nodes  will  have  memo 
components  and  which  will  not.  This  gives  the  programmer  much  better 
control  of  efficiency  in  time  and  storage  than  the  automatic  technique 
suggested  in  [1  ’,  although  at  a  cost  of  requiring  correct  programming. 
Gince  efficiency  is  the  sole  ob.iecti  'e  of  the  memo  technique,  perhaps 
this  is  not  too  high  a  price. 

The  implementation  of  this  mane  technique  perhaps  constitutes  one  of 
the  better  disciplined  uses  of  the  controversial  LISP  functions  RPLACA  and 
RFLACD . 


7  •  Non -shared  Representation, 


In  the  previous  sections  we  have  ;ivcn  examples  for  which  an 
implementation  using  shared  substructures  would  give  significant  savings 
in  storage  space  and  time.  However,  the  use  of  storage  sharing  has  some 
significant  penalties: 

(1)  when  updating  any  component  of  any  node  of  a  structure,  a  new  copy 
must  be  made  of  that  node  and  all  nodes  through  which  it  war 
accessed; 

(2)  storage  which  goes  out  of  use,  either  because  of  updating  or  because 
of  block  exit,  cannot  be  immediately  reclaimed  for  other  uses; 

(3)  the  programmer  tends  to  lose  control  of  the  efficiency  of  use  of  one 
of  his  most  precious  assets,  main  storage; 

(M  the  programmer  has  no  control  over  addressing  vagrancy,  which  is 
necessary  for  successful  use  of  paging  systems  or  backing  stores; 

(5)  the  time  spent  in  scan-mark  garbage  collection  can  be  the  heaviest 
single  cost  in  the  execution  of  an  efficiently  compiled  program. 

These  disadvantages  will  be  particularly  acute  in  cases  where  little 
advantage  can  be  taken  of  sharing. 

Consider  for  example  a  program  operating  on  intsets  (as  defined  in 
Section  5)  which  only  ever  needs  one  such  set;  or  if  it  needs  several,  it 
only  ever  updates  the  sets  by  assignments  of  the  form 

51  :=  insertion(Sl, 57) ; 

52  : =  delet i on ( S2 , 93 ) ; 

and  never  pc:  forms  a  "cross-assignment"  of  the  form: 

51  :=  G2 ; 

52  :=  insertion(Sl, 57) • 

In  such  a  program,  the  two  sets  would  never  in  practice  cane  to  share 
any  subcomponent.  Sven  if  the  program  did  make  an  occasional  cross¬ 
assignment,  the  sharing  patterns  would  be  rapidly  dissipated  by  subsequent 
updating  of  either  set.  Go  in  this  program  a  non-shared  representation 
would  bo  much  better. 


2d 


T 

I  L'  it  :i  s  known  that  the>\  j  s  n  sharing,  the  progra'iuner  must  bo 
f  encouraged  to  use  select!  vc  updating  oL‘  components  ol'  hi  a  structure  by 

mea  s  of  procedure  a  operating  upon  the  at.  nurture,  rather  than  functions 
producing  potentially  large  structured  valuer.  Ac  suggested  an  [12], 
we  shall  declare  procedures  local  to  the  class: 

procedure  insert (i:  integer)  : 
procedure  deleted:  integer)  ; 

These  procedures  are  regarded  aa  being  "components"  of  every  variable  of 
,  the  class,  and  can  be  invoked  by  naming  the  variable  followed  by  the 

J 

procedure  call  ( separated  by  a  dot): 

51 .  a nsert( 57) ; 

52.  delete (95) ; 

which  are  intended  to  be  equivalent  to  the  updating  assignments 

SI  :  incertion(Sl, 57) j 
32  :  delction(S2,9' ) • 

The  writer  of  these  procedures  sometimes  wishes  to  refer  to  the  yet 
unknown  variable  to  which  it  is  being  applied.  For  this  purpose,  we  will 
use  the  name  of  the  class  itself.  In  some  circumstances,  it  is  necessary 
to  define  a  completely  new  value  of  this  variable  bj  means  of  a  generator. 
For  this  purpose.  T  suggest  a  facility  used  in  many  lan^agcs  to  specify 
the  result  of  a  fun e tin,  namely: 
result  e; 

which  has  the  effect  of  assigning  c  as  the  result  of  the  procedure,  and 
immediately  exiting  fru;  the  procedure.  The  code  for  the  updating  version 
of  intset  is  shown  in  Table  1. 

When  the  result  of  a  procedure  is  given  by  result  ,  part  vr  all  of 
the  store  used  by  the  value  of  the  variable  being  updated  can  often  be 
immediately  reclaimed  --  a  tcclmique  which  has  been  called  "compile  time 
garbage  collect!  n"  [15].  An  ex-unple  of  this  is  marked  (2). 

One  con: equenee  of  a  non -si wired  representation  :1s  that  whenever  a 
structure  is  used  as  an  argument  to  a  generator,  a  complete  copy  of  that 
structure  must  be  made .  .An  exception  t:  this  is  in  the  case  of  a  single 
occurrence  of  the  class  name  within  .an  expression  which  'is  being  used  as 
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class  intset  =  (empty j List ( intset, integer) ) 

♦ 

begin  procedure  inrert(i:  integer); 

cases  intset  of  (empty  -  result  list ( empty, i) j 

list(rest,j)  -  if  i  >  j  then  rest,  insert(i) 

j  else  if  i  <  j  then  result  list(intset, i) )  ;  (l) 

procedure  delete(i:  integer)  ; 
cases  intset  of  (empty  -  do  nothing j 

list(rest, j)  —  if  i  =  j  then  result  rest  (2) 

else  if  i  >  j  then  rest .  delete(i) )  ; 
function  has(i:  integer):  Boolean; 
cases  intset  of  (empty  —  result  false) 

list  rest,.])  -»  if  i  =  j  then  result  true 

else  if  i  >  j  then  result  rest,  has(i)); 

intset  :=  empty 

end; 


Table  1. 


t 


a  result  ■  Jn  tbit*  case,  the  .uur.o  address  can  be  used  instead  of  tj 
address  of  a  lresh  copy;  and  of  course,  the  storage  occupied  would  not 
be  reclaimed.  .An  example  of  chi.  i:  marked  '1). 

After  these  two  optimisations  have  been  made,  the  outstanding 
causes  of  ineli iciency  are  the  recursive  calls,  with  their  associated 
overhead  of  stack  manipulation  and  parameter  passing.  Since  these  will 
occur  as  the  last  statement  of  the  procedure  body,  an  obvious  optimization 
would  be  to  replace  them  by  a  .jump  back  to  the  beginning  of  the  procedure 
body,  having  made  appropriate  adjustment  for  the  left  hand  parameter  of 
the  procedure. 

After  these  optimizations  have  been  made,  the  resulting  program  may 
in  certain  applications  be  several  orders  of  magnitude  more  efficient', 
than  the  purely  functional  class  described  in  Section  5* 

It  is  unfortunate  that  the  language  feature  described  here  relies 
so  heavily  on  optimization  to  secure  highest  efficiency.  The  great 
danger  of  optimization  is  that  a  small  change  to  a  program  (e.g.  insertion 
of  n  :  =  n+1  after,  instead  of  before,  a  recursive  call)  will  give  rise  to 
an  unpredictable  and  unacceptable  loss  of  efficiency.  A  second  danger  is 
that  it  can  make  an  implementation,  large,  slow,  unreliable,  and  late. 
Finally,  it  has  the  unfortunate  effect  of  removing  from  the  programmer 
the  feeling  of  responsibility  and  control  over  efficiency,  which  was  the 
main  reason  for  introducing  selective  updating  anyway'. 

Consequently,  it  may  be  desirable  to  introduce  into  a  language 
come  special  notations  for  expressing  the  three  special  cases  which  are 
susceptible  to  optimization. 


Conclusion 


This  paper  has  described  a  number  of  old  programming  techniques 
and  new  notati  ns  to  express  them.  The  ob .iectivo  has  been  t  isolate 
a  number  of  useful  and  efficient  simple  cases  of  the  use  of  references, 
which  are  susceptible  of  relatively  simple  proof  techniques,  and  give 
notations  and  syntactic  conventions  which  guarantee  their  validity. 

In  all  cases  it  has  proved  possible  to  achieve  this  without  introducing 
the  concept  of  a  reference  into  the  algorithms.  Of  course  there  must 
remain  a  number  of  applications,  for  example  when  dealing  with  relational 
structures,  when  the  explicit  use  of  references  seems  unavoidable  or 
even  desirable;  and  for  this  purpose,  something  like  the  record  class 
of  ALGOL  W  still  seems  to  be  the  best  solution. 

However,  if  a  general-purpose  programming  language  contains  a 
record  class  concept,  this  can  certainly  be  used  to  program  all  the 
representations  described  in  this  paper.  So  the  question  arises,  is  it. 
worth  while  to  ine  rporate  these  notations  and  facilities  into  such  a 
language?  The  answer  to  this  probably  depends  on  the  intended  application 
of  the  language.  In  a  special  purpose  language  for  symbol  manipulation 
it  would  be  interesting  to  try  out  some  of  these  ideas;  but  in  a  general 
language  for  implementing  software  (e.  -.  operating  systems),  the  reliance 
on  general  garbage  collection  seems  quite  inappropriate . 

Even  if  these  ideas  are  not  embodied  in  a  programming  language,  I  hop 
they  will  be  found  to  be  useful  as  an  aid  to  reliable  program  design  and 
documentation.  An  algorithm,  can  be  designed  using  the  suggested 
facilities,  and  can  perhaps  even  proved  using  the  suggested  proof 
techniques;  the  programmer  can  then  manually  translate  his  abstract 
program  into  some  lower  level  language  with  explicit  pointers,  using  the 
suggested  implementation  techniques .  This  as,  of  course,  the  general 
metnod  recommended  in  structured,  programming  [ 16 ] . 
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